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Comments on Suitability of Variable Servicer Analog 
Display Routine for Manned LM Flights 


References: (a) MSC FA40, "Latest in Luminary for Apollo 14," dated 24 July 1970, 
received 29 July 1970. 

(b) Revision 31 of AGC Program Zerlina, dated 16 July 1970, received 
24 July 1970. 


Reference (a) indicates that MSC plans to incorporate the landing analog 
display routine of reference (b) into the LM program for the manned Apollo 14 
flight. A review of the coding in reference (b) reveals that the following 
penalties will have to be paid for this MSC decision (when evaluated against the 
performance of the Luminary 173 program): 

1) Luminary 173 (and the Apollo 13 program) had anomaly L-1B-04 fixed, while 
reference (b) does not. Hence if RR error counters should be disabled, then no 
automatic enabling of them is done (a check of bit 2 of channel 12 is needed). 
Although the anomaly report is not available, reference to Luminary memo #121 
indicates that one way for error counter enable to be reset is "when the RR is 
cycled on and off." 

2) Luminary 173 computed information for R1 of N60 (forward velocity) regardless 
of the position of the switch on the spacecraft panel controlling display of data 

on the meters. This change, "authorized" by ACB L-ll (it impacted Section 2 and 
Section 4 GSOPs), is not in reference (b). Consequently, the warning note on 
page 1-7 and 1-49 of the Apollo 14 Flight Crew G&N Dictionary (15 June 1970) that 
proper R1 data "requires MODE SEL - PGNS" for N60 must be retained, whereas its 
deletion was possible if Luminary 173 had been used. 


3) Luminary 173 allowed the maximum display on the crosspointers (at least 

as fed to the error counters) be about 200 fps, in accordance with the information 
on the required range given on page 5*3-118 of the Section 5 Rev. 8 Approved by 
NASA GSOP. Reference (b), however, contains a constant which seems to limit the 
maximum display to only about half this number (the quantity MAX.VEL, line 0140 
on page 43> has a value of 00233g which seems to be about 99*32 x O. 3 O 48 x 0.01 x 2”^, 
where first term is fps, 2nd converts to meters, 3rd to centi-seconds, and fourth 
is scale factor). The program comments indicate a scale factor of "B6", which has 
not been successfully supported by the computations on pages 884-5 * which seem to 
make use of a quantity scaled B5 instead. 

4) Although Luminary 173 made use of single precision computations, it provided 
them with a consistent sign. Page 884 of the listing, however, computes forward 
velocity information as: 

FORVTEMP =M32 VHZ^, - 1422 VHY + M22 VHY+1 

dp sp sp 

It appears that the last term has the wrong sign, thus raising the question, in 
view of presumably successful tests, of whether it needs to be included at all. Its 
omission would save a small amount of execution time. 


5) An apparently influencing factor in reference (a) was that the program 
"begin displaying analog data at TIG - 30 seconds" (item (d) on page l). Since 
Average-G state vector initialization is for TIG - 29*9 seconds, however, the 
first display (setting of a flagbit) would not be expected to be initiated until 
some time after TIG - 27.9 seconds, not "TIG - 30" as specified by MSC. 


Given on the following pages is some information on the equations in reference (b), 
in the event this material may have some relationship to what is nut in the manned 
Apollo 14 program. m ® ^ 3 gf a *\ ra m ~~ ~ ™ ~ 
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Comments on Rev. 31 of LM Variable Servicer Program 


Reference: Revision 31 of AGC Program Zerlina, dated 16 July 1970, received from 
MSC 24 July 1970. 

The following questionable items have been identified as a result of a brief one- 
pass scan of the reference. 


Page 


Comment 


142 



LRWH1 is assigned to E7,1742, the same cell as used for VEX in P40. Hence 
P40 cannot be used prior to P 64 without manually loading LRWH1 again. This 
lockout is in direct conflict with the mission sequence ("nominal") shown 
on page 5.1-14 of Section 5 Rev. 8 Luminary GSOP (approved by NASA), which 
shows P40 being performed prior to the landing programs. Although such a 
performance is not necessarily indicative of MSC flight plans, explicit MSC 
approval to delete the capability (especially when the four landing . 
radar antenna angles are still filling up memory, though unreferenced) must 
be obtained. As described in anomaly L-1D-08, the Luminary 173 location 
for this quantity is also unsatisfactory. Other areas of the program 
reflect the "technology level 
E7,1742 also used for r: 


algo-, (and its anomalies). 
20's RRBORSIT (most sig. naif of Y component}. 


The cells loaded for telemetry in "R12DL" do not satisfy the requirements 
of the Section 2 Rev. 9 GSOP (approved by NASA), which requires that 
the time tag and CDU angle information be for the LR sample (of e.g. 
velocity or range), rather than be the quantities sampled at accelerometer 
read time. The quantities telemetered are appropriate for the Luminary 
173 design; for the reference, information provided should be that read 
by "RDGIMS" instead (as in earlier LM programs). 


815 / The Section 2 Rev. 9\GS0P (approved by NASA) specifies that FIGWRD11 

/ be set 40000 8 by Rl\l "w r hen an abort is requested". This page, at the 
cost of an additional program step, merely sets bit 15 * leaving other 
/bits at their previous value. 


/ 




947 



The Luminary 173 performance "authorized" by ACB L-ll, allowing R1 of 
N60 to be updated even if panel switch not set to cause display, should 
be reflected in the reference also. The design change since Apollo 13 
should have been a PCR, of course, in view of the impact on bit 14 of 
FLAGWRD 1 in Section 2 GSOP, and on RIO in Section 4 GSOP. 

The revised scaling of l/PIPADT (from B 8 to BIO centi-seconds) does not 
seem reflected in the initialization of the cell in "LUNG" for P 57 
purposes. The old B 8 scaling is also reflected on page 339, but the 
setting there is presumably not functional. The P57 use, of course, is 
not exactly two seconds anyhow. 

The decision as to whether the old "two second" cycle should be retained 
in constants or modified should be part of the MSC design review, since 
a "hard-wired" two seconds still seems reflected in the V 57 update rate, 
the "S 4 O. 8 " time-to-go computation, and the computations in the ascent 
equations (see pages 5*3-35, 5-3-144, and 5-3-148 of Section 5 Rev. 8 GSOP). 




